Techniques for digital transmission of video promise increased flexibility, higher resolution, and better fidelity. Recent industry collaborations have brought digital video closer to reality; digital video transmission and storage standards have been generated, and consumer digital video products have begun to appear. The move toward digital video has been encouraged by the commercialization of digital technologies in general, such as personal computers and compact discs, both of which have increased consumer awareness of the possibilities of digital technology.
Personal computers, which have recently become common and inexpensive, contain much of the computing hardware needed to produce digital video, including a microprocessor/coprocessor for performing numeric calculations, input and output connections, and a large digital memory for storing and manipulating image data. Unfortunately, personal computers are not suitable for consumer digital video reception, because the microprocessor in a personal computer is a general purpose processor, and typically cannot perform the calculations needed for digital video fast enough to produce full-motion, high definition video output.
Accordingly, special purpose processors, particularly suited for performing digital video-related calculations, have been developed for use in digital video receivers for consumer applications. A specific processor of this kind is disclosed in commonly-assigned, copending U.S. patent application Ser. No. 08/865,749, entitled SPECIAL PURPOSE PROCESSOR FOR DIGITAL AUDIO/VIDEO DECODING, filed by Moshe Bublil et al. on May 30, 1997, which is hereby incorporated by reference herein in its entirety, and a memory controller for use therewith is disclosed in commonly-assigned, copending U.S. patent application Ser. No. 08/846,590, entitled "MEMORY ADDRESS GENERATION FOR DIGITAL VIDEO", filed by Edward J. Paluch on Apr. 30, 1997, which is hereby incorporated herein in its entirety.
The above-referenced U.S. patent applications describe an application specific integrated circuit (ASIC) for performing digital video processing, which is controlled by a reduced instruction set CPU (RISC CPU). The RISC CPU controls computations and operations of other parts of the ASIC to provide digital video reception. As is typical of CPU's of many varieties, the CPU described in the above-referenced U.S. patent applications supports flow control instructions such as BRANCH, CALL and RETURN, as well as providing hardware interrupt services.
However, as is typical of RISC CPU design, for simplicity and savings of chip area, the functionality of the RISC CPU described in the above noted U.S. patent applications is limited in several ways. First, the RISC CPU does not include any support for a stack, and thus cannot support nested procedures calls, or nested interrupts. Whenever a CALL instruction is executed, the return address for that call is stored in a single on-chip register. If another CALL instruction is executed, the previous return address is lost, and an error will result. Whenever an interrupt occurs, the RISC CPU branches to the associated interrupt service routine, and ignores all other interrupts until a RETURN is encountered at the end of the interrupt service routine.
A second limitation of the RISC CPU described in the above-referenced U.S. patent applications, is the size of the instruction memory available to the CPU. As described in the applications, the instruction memory is limited to 4096 instructions, which is a relatively small space; however, in some lower-density applications, the instruction memory might be further limited, for example to 2048 or fewer instructions, in order to conserve chip area.
These limitations of the RISC CPU described in the above-referenced U.S. patent applications, present difficulties in programming the RISC CPU for digital video decoding. Firstly, it is preferable to write software for a CPU in a modular fashion, such that those portions of the software that are used repeatedly, are incorporated into subroutines that can be called from other locations in the program. This approach reduces the total number of instructions in the program by making repeated use of common sets of instructions. Unfortunately, to take full advantage of this approach, it is often necessary to nest procedure calls, i.e., to permit subroutines to call other subroutines. If procedure calls cannot be nested, as is the case in the RISC CPU described in the above-referenced U.S. patent applications, it can be difficult to write software in an efficient, modular fashion.
Furthermore, it can be difficult to provide sufficient digital audio/video decoding functionality in a program which is limited to 2048 or even 4096 instructions. Thus, the small size of the instruction memory provided by the RISC CPU of the above-referenced U.S. patent applications presents a serious limitation on the functionality that can be provided.
Finally, difficulties arise from the nature of digital video processing. Digital video decoding involves a wide variety of digital processing tasks, some of which are time-critical (such as video "slice" decoding for display) and some of which are substantially less time critical (such as on-screen display and subtitle processing). As to time-critical tasks, the RISC CPU must detect when processing is needed and instruct other elements of the ASIC to respond appropriately, and must do so in a timely fashion.
One approach to providing this functionality, would be to associate each decoding task with an interrupt; when certain processing is needed, the associated interrupt is delivered to the CPU, causing the CPU to respond by branching to the associated interrupt service routine, and thereby performing the necessary actions. Unfortunately, when used in the RISC CPU described in the above-referenced U.S. patent applications, this approach could fail to provide the required responsiveness to time-critical tasks, because that RISC CPU does not permit nesting of interrupts. As one example of the problems that could occur, an interrupt for a non-time-critical task, might be delivered to the CPU just prior to an interrupt for a time-critical task. If this occurs, and if the interrupt service routine of the non-time-critical task is relatively lengthy, servicing of the time-critical task might be unacceptably delayed, since during the interrupt service routine for the non-time-critical task, no further interrupts will be serviced.